1. Field of the Invention
The present invention relates to a method and related program for selective suspension of devices, and in particular, related to a dual-stack driver architecture for selective suspension of universal serial bus (USB) devices.
2. Description of the Related Art
Devices such as universal serial bus (USB) devices are increasingly popular in computer systems. As a result, computer software operating system (OS) programs typically include drivers for interfacing with the USB devices through the input/output (I/O) ports of the computer system.
Many widely used computer OS programs, such as the Windows™ NT developed by Microsoft, often have two main components, a user component for handling user applications and a kernel component for bridging the user applications and the actual data processing done at the hardware level. The kernel component typically manages the system's resources and communication between hardware and software components, and often provides a low-level abstraction layer for the system's resources (especially processors and I/O devices) that application software must control to perform their functions. The kernel component also makes these resources available to application processes through inter-process communication mechanisms and system calls. In this connection, the OS programs often segregates the virtual memory into a user space for user applications and a kernel space for running kernel, kernel extensions and most device drivers. Some of these device drivers include Network Driver Interface Specification (NDIS) miniport driver using the Windows Driver Model (WDM) or the Windows Driver Foundation (WDF) (also known as NDIS/WDM/WDF drivers).
Referring to FIG. 1, there is illustrated a conventional driver architecture, including a user space with applications 10, and a kernel space with NDIS miniport driver 20 and USB driver stack 40, for interfacing with hardware USB network device 50.
In this architecture, the WDM/WDF driver is in the same driver stack of the miniport driver. However, in some OS programs, such as Windows™ XP and Windows™ Vista, the NDIS miniport driver is not allowed to use USB selective suspend mechanism. This is because in such OS (e.g., Windows™ XP or Vista), only a power policy owner, i.e., the function driver, may issue a power I/O request packet (IRP) to suspend a USB network device. But in the driver architecture shown in FIG. 1, the NDIS miniport driver is also the function driver, yet the OS does not allow it to issue a power IRP. This is problematic as it is often desirable to selectively suspend one or more USB network devices to save host and the device power consumption while a network device is in disconnected state, yet the clashes of the OS restriction or limitation prevents the USB network devices to enter a suspend mode which reduces power consumption by both the host and the network device.
Moreover, after an USB network device enters suspended mode, some OS embodiments (e.g. Windows™ XP or Windows™ Vista) do not allow user applications access the device directly. Again this is problematic because it is also often desirable for a user application to directly access a suspended USB network device (to “wake” it up directly and use it), yet the OS restriction or limitation prevents the USB network devices be directly accessed by user applications while they are suspended and cannot be waken up by the user application directly.
Although NDIS miniport driver is discussed above as an example, these problems exist for other types of drivers as well.
Therefore, it is desirable to provide a driver architecture that allows selective suspension of an USB or I/O device to reduce power consumption by the host and the device, and also allows a suspended USB or I/O device be directly accessed by user applications.